Ian & Stuart's Australian Mac 1993 September

home *** CD-ROM | disk | FTP | other *** search

/ Ian & Stuart's Australian Mac 1993 September / September 93.iso / Community / BBS / BBS Networks / Fidonet / SIGNet Policy < prev next >

Wrap

Text File | 1991-09-29 | 50.5 KB | 1,476 lines | [TEXT/R*ch]

SIGnet Policy and Procedure Document Version 3.00.d DRAFT VERSION - July 1, 1991 revised July 26, 1991 revised August 9, 1991 Table of Contents Section 1 - SIGnet Overview 1.1 Description 1.2 Purpose 1.3 Fees and Cost Sharing 1.3.1 Cost Sharing Amendments 1.3.2 SIG Fees 1.4 Exclusion of Members 1.5 Policy Document 1.6 General Behaviour 1.7 Official Language Section 2 - SIGnet Structure 2.1 Basic Topology 2.1.1 Splitting Zones 2.1.2 Splitting Regions 2.1.3 Splitting Nets 2.1.4 General Information on Splitting 2.2 Zone Addressing 2.3 Zone Allocation 2.4 The SIGnet Domain 2.5 Regions 2.6 Nets 2.7 Net Mail Hour (NMH) Section 3 - SIGnet Administration 3.1 Administration of SIGnet 3.1.1 Replacing the IC 3.2 International Coordinator - IC 3.3 Zone Coordinator - ZC 3.3.1 ZC Duties 3.4 Zone Echo Coordinator - ZEC 3.4.1 ZEC Duties 3.5 Zone Technical Coordinator - ZTC 3.5.1 ZTC Duties 3.6 Regional Coordinator - RC 3.6.1 RC Duties 3.7 Regional Echo Coordinator - REC 3.7.1 REC Duties 3.8 Net Coordinator - NC 3.8.1 NC Duties 3.9 Net Echo Coordinator - NEC 3.9.1 NEC Duties 3.10 Ombudsman Section 4 - Disputes and Complaints 4.1 Filing a Complaint 4.2 Appealing a Decision 4.2.1 Making the Appeal 4.3 Limitations 4.3.1 Time for Filing Complaint 4.3.2 Time for Responding to Complaint 4.3.3 Time for Trial 4.3.4 Basis for Decision 4.3.5 Time for Making an Appeal 4.3.6 Extent of Arbitration 4.4 Handling the Dispute Section 5 - Elections 5.1 Administration 5.2 Terms of Office 5.3 Calling an Election 5.4 The Election Process 5.4.1 Electing a Vote Counter 5.4.2 Nominations and Candidates 5.4.3 The Election Date 5.4.4 Ballots 5.4.5 Election Returns 5.4.6 Installation of New Administration 5.4.7 Maximum Terms 5.4.8 Cancelled Elections 5.4.9 Maximum Offices 5.5 Vote of Confidence Section 6 - The Nodelist 6.1 Distribution 6.2 Nodelist Structure 6.3 Special Node Numbers 6.4 Archive Format 6.5 Official Editing and Distribution 6.6 GateWay Nodes 6.7 Support Nodes Section 7 - Obtaining a Node Number 7.1 Responsibility of Assignment 7.2 Availability and Eligibility 7.3 Exclusion 7.3.1 Limitations of Bans 7.4 Limit of Nodes 7.5 Private Nodes Section 8 - Echomail Conferences 8.1 Different Types of Echomail 8.2 Gated Echomail 8.3 Censorship 8.4 Cutting off Mail Flow 8.5 Moderators of Gated Echos 8.7 Making a Profit from Echomail 8.8 Sysop's Responsibility 8.9 Echohubs 8.10 Profane or Illegal Messages 8.11 Legal Action Due to Conferences 8.12 Personal Opinions and Beliefs 8.13 Origin Line Address 8.14 Echomail Conference Tag Structure 8.15 Mandatory Conferences 8.16 Echomail Backbone 8.16.1 Backbone Coordinator Section 9 - Gateways 9.1 Gateway Definition 9.2 Netmail Gateways 9.2.1 Netmail Gating Automation Section 10 - Technical Specifications 10.1 Technical Specifications 10.2 Technical Amendments 10.2.1 Local Policy Documents 10.3 Echomail Conference Tags 10.3.1 Conference Tag Examples 10.3.2 Tag Exceptions 10.4 Echo Useage Section 11 - Cost Sharing 11.1 Zone Level 11.2 Regional Level 11.3 Net Level Section 12 - Policy Changes 12.1 Initiating Amendents 12.2 Local Policy Section 13 - Copyright and Ownership of SIGnet 13.1 Copyright Notice ˙ This policy document was designed solely for the purpose of providing guidelines for certain levels of administration to operate in a manner which coincides with the rest of the network on a day to day basis. Some portions of this document must be strictly adhered to and clarification is made at that time by suggesting a penalty for breach of policy. Section 1 - SIGnet Overview 1.1 Description SIGnet is a network, open to all and any electronic bulletin boards, public or private, anywhere in the world to anyone using a front-end mailer system that is capable of the FTSC standard packet and handshake format. 1.2 Purpose SIGnet exists simply as a group of systems freely exchanging information between some or all of the systems listed in the SIGnet nodelist. SIGnet's purpose is to provide an international medium in which people of different cultures with different interests can share discussion with other people. SIGnet strives to provide this in a friendly, open atmosphere which is obtainable without considerable difficulty by any system in the nodelist. SIGnet also strives to create an umbrella under which unique special interest groups may have a free and common medium in which to communicate both amongst themselves and with other groups which may have similar or different interests. 1.3 Fees and Cost Sharing There are absolutely no fees to join SIGnet or to receive the mail other than the costs incurred in normal pick-up or delivery of mail as charged by your local telephone company or long distance service subscription. 1.3.1 Cost Sharing Amendments Some geographical areas may implement cost-sharing methods by way of the democratic process as outlined in this document. These cost-sharing amendments are outlined in Section 11. 1.3.2 SIG Fees Special Interest Groups operating under the infrastructure of SIGnet may choose to charge fees to their particular members. This fee may not be charged to people outside of the membership of that SIG. SIGs operating in SIGnet will not be charged a fee for their operation or for the service of their mail but may be required to allow general distribution of echos within SIGnet in exchange for operating on the SIGnet backbone. 1.4 Exclusion of Members There shall be no exclusion of anyone from joining SIGnet based on race, sex, creed, religion, age, colour, or nationality. SIGnet does not exclude any individual based on their membership in other networks, unless a common inter-network body, of which SIGnet is a member, has recommended a ban of the sysop. 1.5 Policy Document This policy document contains all of the rules, regulations, guidelines, and procedures needed at all points of administration in SIGnet for the complete operation of the network. Any node may be brought up on charges of policy violation as directed in this document. 1.6 General Behaviour SIGnet is based on the basic ideals of fairness and friendship. Public flaming will not be tolerated. If you feel the need to flame or argue with another individual in the network, it should be done in private so as not to disrupt the entire network. Putting down an individual who is not a member of SIGnet will also not be tolerated. 1.7 Official Language The official language of SIGnet is and shall remain as English. Although this document may be freely translated into other languages, the text, contents and intent of the clauses contained herein are to be considered correct and proper as written and interpreted in the official language. Section 2 - SIGnet Structure 2.1 Basic Topology SIGnet consists of a series of zones based on their geographical layout. Within these zones are regions. There may be a maximum of 30 regions per zone. In each region, there may be a maximum of 30 nets. There may be a maximum of 32,766 nodes in a net. At no time should the administrating body of the network allow a net to exceed its ability to properly execute its purpose. 2.1.1 Splitting Zones At such a time that either a Zone Coordinator or the International Coordinator feels that a zone encompasses too much area to run properly or that for any reason the zone should be split into more than one area, the IC (International Coordinator) may, at his discretion, split the zone and allocate a new zone number to the new zone. 2.1.2 Splitting Regions Should a region become too congested to function properly, the ZC (Zone Coordinator) or the RC (Region Coordinator) may opt to have the region split. The ZC will then split the region and assign the new region a separate region number. 2.1.3 Splitting Nets Should a net become too congested to function properly, the RC (Region Coordinator) or the NC (Net Coordinator) may opt to have the net split. The RC will then split the net and assign the new net a separate net number. 2.1.4 General Information on Splitting In the event of any geographical area splitting, the individual responsible for assigning the new number should also appoint a new coordinator for the area. In addition, the new coordinator shall be provided with information on nodelist updates and should provide their immediate admin uplink with a nodelist update for processing. 2.2 Zone Addressing All zones except for one are currently based on their geographic location. It is, however, fully SIGnet's intention to do away with the four dimension addressing scheme and implement a domain-type system at a date in which compatibility with software is no longer a problem. 2.3 Zone Allocation Currently, SIGnet has allocated six zones. Zone numbers have been allocated for future expansion should the need arise. These zone numbers and their geographic limits may change at any time. Currently, the following zones have been allocated for use in SIGnet: Zone 24 SIGnet Administration Zone 25 Western Canada and Alaska Zone 26 Continental United States Zone 27 Europe Zone 28 Australia, New Zealand and South Pacific Zone 29 Asia Zone 30 Africa Zone 31 South America Zone 32 Central Asia Zone 33 Western Asia and Middle East Zone 34 Eastern Canada 2.4 The SIGnet Domain SIGnet currently operates and recognizes only one domain signature. Domain usage should only contain @signet as the domain signature. At this time, any additional characters in the domain signature will be ignored. It is fully the intention of the IC to establish a technical committee to research and develop a unique and functional domain system for SIGnet. 2.5 Regions Regions are allocated by the ZC by geographic location. It is entirely up to the ZC to devise a unique scheme of numbering regions. It is strongly recommended that the area code or country code should be used to avoid duplication of net numbers in different zones. Should the ZC wish to use a numbering scheme not associated with area codes or country codes, consultation with the other ZCs should be made to avoid duplication of numbering schemes. 2.6 Nets Nets are allocated by the RC based on geographic location. Generally, more than one net should not cover the same geographic area that another net covers. This may not be feasible should the density of a particular area be so great that a single net would simply not cover it effectively. Net numbers are based on the region number and are to be assigned by the RC. The region number is simply prefixed by a numerical indicator until the maximum number of nets is reached. For example, in Region 492, the nets would be assigned as 1492, 2492 ... 30492. 2.7 Net Mail Hour (NMH) (i) All systems are required to be able to receive or pickup mail during this time. (ii) NMH is established to be during the period of 1:00am to 2:00am in the time zone to which you belong. Exceptions to this section are allowed by general consensus on a zone basis in coordination with the ZC. Section 3 - SIGnet Administration 3.1 Administration of SIGnet Generally, SIGnet will be administered on each level by an elected individual. These include the zone, region, and net levels. The IC of SIGnet shall oversee the entire operation of SIGnet and maintain the direction and intent of the network. 3.1.1 Replacing the IC The IC may only be removed from position under two circumstances: a) the IC may resign by giving ample notice in which an election shall be held. Should no member be willing to become IC after a resignation, one of the ZCs may assume the IC position for a three month period, after which a new election must be called; b) an absolute vote of confidence by a response of no less than 75% of all members listed in the SIGnet nodelist voting for the forced resignation of the IC. Should less than 75% of the members respond, the vote of confidence shall be null and a new vote of confidence may not be held for a three month period. Following the impeachment of the IC, an election must be held within thirty days. Should no other replacement be found, the original IC must be reinstated immediately and a new vote of confidence may not be held for a three month period. 3.2 International Coordinator - IC The IC shall oversee all administration objectives of the network including new policy development, consultation with all levels of administration in policy interpretation, network structure, and dispute and appeal mediation. (i) In addition, it is the IC's duty to promote SIGnet in good faith to other networks, sysops and future sysops, and the general public in any way that he sees fit. (ii) It shall also be the duty of the IC to produce and distribute the SIGnet nodelist once per week as outlined in this document. (iii) The IC may, from time to time, appoint members of SIGnet to special committees to develop policy and technical specification. 3.3 Zone Coordinator - ZC Each zone in SIGnet, with the exception of the administration zone, must elect a Zone Coordinator (ZC). In the case of the administration zone, the IC shall also be considered to be the ZC in cases where the ZC acts without conflict of the ZC/IC roles (ie: zone administration). 3.3.1 ZC Duties The ZC shall: (i) compile nodelist updates for submission to the IC for compilation; (ii) distribute the following files to the RHs in their zone for distribution: - SIGDIFF.Z?? - SNEWS???.ZIP - SIGECHO.Z?? (iii) assign new regions in their zone as needed in compliance with this policy; (iv) maintain the smooth flow and operation of their zone in SIGnet; (v) work with the ZEC to assure smooth flow of echomail in their zone; (vi) act as an inter-zone netmail hub for the members in their zone. 3.4 Zone Echo Coordinator - ZEC Each zone in SIGnet, with the exception of the administration zone, must elect a Zone Echo Coordinator (ZEC). In the case of the administration zone, the IC shall appoint an International Echo Coordinator (IEC). 3.4.1 ZEC Duties The ZEC shall: (i) distribute all mandatory echos to all downlinks in their zone; (ii) shall make available to all downlinks all echos originating in SIGnet as well as optionally allowing echomail gated into another zone; (iii) make available to any system in their zone, a list of all echomail conferences available to the systems in their zone. 3.4.1.1 Should the zone choose, the ZC may also perform the duties of the ZEC. In this case, the ZC shall maintain both nodelist entries. 3.5 Zone Technical Coordinator - ZTC Each zone in SIGnet, with the exception of the administration zone, a Zone Technical Coordinator shall be appointed by the ZEC and ZC. 3.5.1 ZTC Duties The ZTC shall: (i) be a backup system to the ZC and ZEC in the event that either party is unable to perform their function until such time that the problem can be rectified or an election take place; (ii) act as a technical advisor to the ZC and ZEC at their request. 3.6 Regional Coordinator - RC Each region in SIGnet must elect a Regional Coordinator (RC). 3.6.1 RC Duties The RC shall: (i) compile nodelist updates for submission to the ZC for compilation; (ii) distribute the following files to the Nhs in their region for distribution: - SIGDIFF.Z?? - SNEWS???.ZIP - SIGECHO.Z?? (iii) assign new nets in their region as needed in compliance with this policy; (iv) maintain the smooth flow and operation of their region in SIGnet; (v) work with the REC to assure smooth flow of echomail in their region. 3.7 Regional Echo Coordinator - REC Each region in SIGnet must elect a Regional Echo Coordinator (REC). 3.7.1 REC Duties The REC shall: (i) distribute all mandatory echos to all downlinks in their region; (ii) shall make available to all downlinks all echos available in their zone; (iii) make available to any system in their region, a list of all echomail conferences available to the systems in their zone. 3.7.1.1 Should the region choose, the RC may also perform the duties of the REC. In this case, the RC shall maintain both nodelist entries. 3.8 Net Coordinator - NC Each net in SIGnet must elect a Net Coordinator (NC). 3.8.1 NC Duties The NC shall: (i) compile nodelist updates for submission to the RC for compilation; (ii) distribute the following files to the nodes in their net; - SIGDIFF.Z?? - SNEWS???.ZIP - SIGECHO.Z?? (iii) assign new node numbers in their net as needed in compliance with this policy; (iv) maintain the smooth flow and operation of their net in SIGnet; (v) work with the NEC to assure smooth flow of echomail in their net. 3.9 Net Echo Coordinator - NEC Each net in SIGnet must elect a Net Echo Coordinator (NEC). 3.9.1 NEC Duties The NEC shall: (i) distribute all mandatory echos to all nodes in their net; (ii) shall make available to all nodes all echos available in their zone; (iii) make available to any system in their net, a list of all echomail conferences available to the systems in their zone. 3.9.1.1 Should the net choose, the NC may also perform the duties of the NEC. In this case, the NC shall maintain both nodelist entries. 3.10 Ombudsman Any level of administration in SIGnet may choose to put forth an election for an Ombudsman to handle disputes at their level. Should the administration choose not to elect the Ombudsman, the *C shall assume responsibility for handling disputes. Section 4 - Disputes and Complaints 4.1 Filing a Complaint If you feel that you have the grounds to register a complaint, you must determine which level to file it at. (i) a policy dispute or complaint must be filed at the first level of administration at which both parties are affected. For example if 25:1604/999 wishes to file a complaint against someone in the same net, then the complaint goes to the NC1604 (or the Ombudsman if one exists). But, should that same node which to file a complaint against 25:2403/999, then the complaint is made at the zone level. Taking it further, should that same node wish to file a complaint against someone in a different zone, then the complaint must be filed with the IC. (ii) regardless of geographical proximity, the level of administration and nodelist layout shall be used to determine which level a complaint must be filed at. (iii) to file a complaint, the plaintiff need only netmail the proper individual with specifics regarding the complaint. In order for the complaint to be accepted, all parties involved in the complaint must be copied on the message. 4.2 Appealing a Decision If you feel that you have the grounds to appeal a decision made, regardless of whether you are the plaintiff or the defendant, you may appeal the decision to the IC (or prior to appealing to the IC you may be heard by your ZC should they opt to hear your appeal). (i) any decision made by the IC with regards to the appeal shall become final and binding and shall not be overturned by any person in SIGnet; (ii) the IC may make any reasonable requests for proof, testimony he desires and must issue a decision within 30 days of hearing the appeal. 4.2.1 Making the Appeal In order to appeal a decision, the party need only send netmail to the IC with specifics regarding the case and its outcome. In order for the IC to accept the appeal, all persons involved in the previous trial must be copied on the message. (i) the IC may, for whatever reason he sees fit, choose to not hear an appeal in which case, the previous decision shall become final and binding. The IC may alternatively choose to appoint another member (usually a ZC) to hear the appeal for cases within their own zone. 4.3 Limitations In order to expedite the complaint process, some limitations shall be made with regards to policy disputes and complaints. 4.3.1 Time for Filing Complaint The plaintiff must file his or her complaint no longer than 21 full days from the date of discovering the offending action. 4.3.2 Time for Responding to Complaint The person responsible for hearing the complaint shall confirm that the complaint or dispute is valid no longer than 14 days after receiving the complaint. 4.3.3 Time for Trial The trial shall begin no later than 38 full days after the date that the offending action took place. 4.3.4 Basis for Decision All parties involved in making a decision with regards to a complaint shall use common sense and good judgement. Local criminal codes shall supplement this document where needed to provide a working document for the basis of a decision. (i) it is not SIGnet's intention to replace the civil justice system but the legal system within SIGnet shall use pertinent civil law as a basis for decisions in policy disputes, violations and complaints. 4.3.5 Time for Making an Appeal Should an appeal be wished to be made, it must be filed with the IC no longer than 21 full days after the initial decision has been made. 4.3.6 Extent of Arbitration No court in SIGnet (or any other computer network) shall have the power to render a decision which would nullify or go against the general workings or intent of this policy document. 4.4 Handling the Dispute The person responsible for handling a dispute may elect to handle the dispute on their own or by means of a jury. (i) a jury shall be selected by means of appointment by the individual responsible for handling the dispute and all members of the jury shall be agreeable by both the defendant and the plaintiff. (ii) notice of 'jury duty' must be made by netmail within the time limits noted above and the message must be copied to all individual involved in the dispute. (iii) a private echomail conference should be established linking all parties involved in handling the dispute. No discussion of the trial shall be made until such time that all parties have established contact in the conference. The person responsible for handling the dispute shall also be responsible for archiving all dialogue in the conference. All dispute archives must be kept for 30 days past the date the decision is made. Section 5 - Elections 5.1 Administration As outlined in Section 2, most every level of administration in SIGnet is performed by members of the network elected into their position by a majority vote of members in their geographical jurisdiction. It is believed that by using this process, the people will be more fairly represented in policy discussions and the general direction of the network by people whom they have elected to represent them. 5.2 Terms of Office No elected person shall remain in office longer than 12 months without seeking re-election (with the exception of the IC). Persons appointed to positions by an administrator are also subject to the same length of term. 5.3 Calling an Election Upon acceptance of this policy document, all current administration positions shall continue their term for twelve months or until the period for a new election as noted in section 5.3 (i) (whichever is longer). (i) The following levels of positions shall be elected in each calendar year no later than the following months: Zone December Region May Net October (ii) inability or failure to complete a term of office shall initiate the beginning of an election for that position and the newly elected official shall complete the term until the next general elections begin. 5.4 The Election Process 5.4.1 Electing a Vote Counter A brief and informal election should take place within the election area to elect a vote counter for the term of the election. The VC may retain this position for a period not exceeding one year without re-election. 5.4.2 Nominations and Candidates Once a Vote Counter (VC) has been installed, submissions for candidacy should be submitted to the VC. All names submitted for candidacy must be verified and accepted by the potential candidate (ie in the case of someone unknowingly being nominated). 5.4.3 The Election Date The VC shall establish a certain date on which the election shall take place. (i) the announcement of an election date shall be no sooner than 5 days and no later than 21 days from the election itself. (ii) the actual length of an election may not exceed five full days. 5.4.4 Ballots All elections should be done via electronic vote management software (similiar to VoteMgr). The IC shall always make this software available to any level. A simple request via netmail will get the software routed to you. 5.4.5 Election Returns The final vote count shall be published in an echomail conference which covers the entire geographical area in which the election is taking place. In addition, the results should be made available to the ZC or IC for archiving purposes in case a reelection is called. Publishing of the results shall take place no more than 5 days after the end of the election. 5.4.6 Installation of New Administration The newly elected administration shall be inserted into the nodelist and take office on the second nodelist update following the election results. This should give ample time to set up links and make any software changes necessary. 5.4.7 Maximum Terms No person shall be restricted in the number of terms that he or she may be elected for. 5.4.8 Cancelled Elections If, for some reason, an election must be redone (ie system crash and lost ballots, etc), the process should be restarted at section 5.4.3. 5.4.9 Maximum Offices With the exception of appointed positions in Zone 24, no single person may hold a position in more than one level of administration at a time. 5.5 Vote of Confidence Upon application to the *C (or *EC should the *C be the subject of the vote), a vote of confidence may be called. All members of the affected area shall follow the voting procedure as outlined in this document in section 5.4.x. (i) should a position be revoked by a vote of confidence, the member shall retain the position until a full election is called. (see Section 5.3 (ii)) (ii) a member who has failed a vote of confidence is free to run for election again. (iii) should a member who has failed a vote of confidence be the only nominee in the new election, he or she shall be appointed without an election and a vote of confidence may not be called again until the normal term of office has expired. (iv) a petition of no less than 25% of the members in the territory must be received to initiate a vote of confidence. Section 6 - The Nodelist 6.1 Distribution The SIGnet nodelist update shall be distributed weekly by the ZCs, to the RCs, to the NCs and finally to the individual nodes. (i) the up-to-date nodelist shall also be available for freq from the IC. (ii) the nodediff shall be hatched into the zone via a TICK echo of the ZCs choice; (iii) each ZC (and the IC) shall publish their nodelist update into the TICK echo called SIG.UPDATES each and every Thursday. no later than 10:00pm in their respective time zone. Each update shall be transmitted via this echo to each ZC (and the IC) for compilation into the Zone nodelist. Each ZC shall be responsible for collecting these updates, processing them, and hatching the nodelist for distribution into their zone. No ZC shall be allowed to edit or omit an update from another zone without written permission from that ZC (or the IC). 6.2 Nodelist Structure The flags and general structure of the nodelist shall conform to current FTSC standards which presently call for a St. Louis style nodelist. 6.3 Special Node Numbers Certain administration positions shall require uniformity throughout the nodelist. They shall be as follows: *C xxx:yyy/0.0 *EC xxx:yyy/1.0 ZTC xxx:xxx/2.0 Ombudsman xxx:yyy/3.0 (i) no other node segment under 10 shall be issued without prior consent from the IC. Numbers 4 through 9 shall be reserved for future use at all levels of SIGnet with the exception of Zone 24. 6.4 Archive Format The nodelist and nodediff shall be distributed weekly in a compressed format using the most recent version PKZIP. (i) the naming method of the compressed file shall be as follows: SIGNODES SIGNODES.Zxx SIGDIFF SIGDIFF.Zxx where xx is the last two digits of the day number. 6.5 Official Editing and Distribution No person, other than the respective ZC (or the IC), shall edit or distribute the official release copy or any other copy for release of the SIGnet nodelist or nodelist update file. 6.6 GateWay Nodes All official inter-network gateways are required to maintain a node number in Zone 24 for the purpose of netmail routing. Local gateways established for the purpose of echomail gating are not required to maintain this arrangement. Non-official listings need not retain a zone 24 number. 6.7 Support Nodes All systems acting as support and distribution nodes shall maintain node numbers in Zone 24 only if they have been designated as a SIGnet network wide support and/or distribution site. Should they only require the designation on a zone wide basis, then that zone shall maintain the node number. Section 7 - Obtaining a Node Number 7.1 Responsibility of Assignment SIGnet node numbers are given out in local nets by the NC. It is the job of the NC to determine that an accepted node has received a copy of this Policy document, and that the node understands and agrees to abide by the policies laid out herein. 7.2 Availability and Eligibility In order for a system to obtain a SIGnet node number, their request for the node number must be made via netmail. Private email and echomail shall not be sufficient proof that the system is mail capable. In addition, the potential node must be able to receive or pickup mail during NMH (see section 2.7). 7.3 Exclusion As per section 1.4, no individual shall be excluded from joining SIGnet for any reason whatsoever except in the event of an international ban based on proven behaviour in other networks. 7.3.1 Limitations of Bans Should an individual be banned from SIGnet or any other network, they shall only banned from SIGnet for a period not exceeding 3 years. At this time, they may reapply for a node number in SIGnet. 7.4 Limit of Nodes No system shall retain a node number in more than one net. 7.5 Private Nodes SIGnet supports and encourages the use of the PVT flag in the nodelist for private nodes and points. The use of points is discouraged (but allowed). Setting up a PVT node is a far better alternative as it allows the proper distribution of information between people. A PVT node shall have the same rights and be under the same regulations as a standard entry as is outlined in this document. Section 8 - Echomail Conferences 8.1 Different Types of Echomail For general usage, there shall be only two distinct types of echomail in SIGnet. (i) SIGnet Originating - this shall be a conference which is available only within SIGnet or a conference which originates within SIGnet and may be gated out to other networks. (ii) Gated/Imported - this shall be a conference which originates outside of SIGnet and is gated into the network properly and legally. 8.2 Gated Echomail All gated echomail shall be bound by certain restrictions. 8.2.1 Any echomail conferences being gated into SIGnet may only be gated by systems authorized by the ZEC. 8.2.2 Any echomail conferences being gated into SIGnet and porting across zones must have the authorization of both ZECs. 8.2.3 Foreign path and seen-by lines must be removed and the gateway's SIGnet node number placed in those fields. 8.2.4 Echotags are required to be changed into a format as designated in section 10. (i) Except for the actual gateway, echotags are not allowed to be changed within SIGnet for any reason whatsoever. 8.2.5 The PATH line is a SIGnet requirement. The information is vital to the trouble-shooting of echomail problems within SIGnet. A *EC may legally refuse to accept or supply echomail from or to any node that does not support the path line. It is a severe violation of policy to strip path lines within SIGnet. 8.2.6 All mail being gated into SIGnet is required to be dupe-proof upon return to the gateway system. In other words, mail gated into SIGnet must not be able to return back through the gateway under any circumstances. 8.2.7 All mail gated in or out of SIGnet shall be required to have the original origin line stripped out and replaced with an origin line containing the SIGnet address of the gateway system. 8.2.8 Where possible, the origin address of the message must be maintained somewhere within the message text in such a fashion that no gateway processor will remove it. The section is applicable to mail both incoming and outgoing through the gateway. 8.2.9 Gated echomail headers must all be adjusted to show the gate address instead of the original 'To:' address. 8.2.10 Tear lines may be removed at the gateway so long as they are replaced with the name of the gateway processor. At no time in SIGnet shall a system release a message with a tear line in excess of 30 characters in length. 8.2.11 A user or sysop may only quote what is necessary to maintain a reasonable thread in an echomail conference. The conference moderator has the discretion to set such limits as he or she sees fit. 8.3 Censorship The use of automated or manual censorship tools in SIGnet is expressly forbidden. The use of such tools will be grounds under the terms of this document for expulsion by the IC from SIGnet without notice. 8.4 Cutting off Mail Flow No node shall be permitted to control the flow of any echomail conference or netmail being routed their system between zones for any reason whatsoever without the express written permission of the IC. Any system making any threat or performing any action which results in any number of systems being without mail without just cause will be expelled from SIGnet without notice. (i) Similiar to section 8.4, no node shall be permitted to control the flow of any SIGnet echomail conference or netmail routed through their system for any reason whatsoever without the express written permission of the ZEC. 8.5 Moderators of Gated Echos All conferences being gated into SIGnet from other networks shall be moderated by the moderators from the foreign network and SIGnet nodes shall conform fully to the requirements of the conference moderator. 8.5.1 Any node repeatedly not conforming to the rules of an imported conference will have its feed of the conference terminated without warning. If you are unsure about the rules, ask the moderator. 8.6 Only the ZC, ZEC and IC may request that a node's entire mail flow be terminated. This shall only be requested in a situation where mail feeds may be in jeopardy. 8.7 Making a Profit from Echomail No entity in SIGnet shall be allowed to make a profit from the distribution of conferences or any other publicly distributed material. 8.8 Sysop's Responsibility Sysops of nodes are solely responsible for mail entered on their system and are expected to take action generally regarded as appropriate assuming the message entered by a given individual does not meet generally accepted standards. Further, the sysop of the system on which the message was entered shall make a full report to the net as to what has been done to eliminate the situation. 8.9 Echohubs NECs may appoint echohubs to assist them in the distribution of echomail. This position shall be noted as HUB in the nodelist. 8.10 Profane or Illegal Messages Should a message containing profanity or illegal material be entered into echomail and go into distribution, it shall be the duty of the sysop to delete the message on their system but shall not cause the message to not continue through normal distribution. Should a complaint arise regarding that message, it should be sent via netmail to the ZC. Under no circumstances should the offending message be requoted. All further discussion regarding the offending message should be done via netmail so as not to keep the issue in a thread. It will be the duty of the ZC to inform, via netmail, the sysop of the system from which the message originated regarding the message. The sysop, by his own means and regulations, prevent the author of the message from having access to echomail thereafter. Should the sysop not take action against the user and prevent him or her from repeating the violation, the ZC should, via netmail, inform the ZEC of the repeat violation and have offending sysop suspended from echomail feeds until the situation can be fully rectified. (i) Conference moderators of adult echos may choose to allow profanity in their conferences. This shall not constitute violation of policy so long as the conference rules are made available and posted in the echo no less than once ever two weeks, and the echotag is designated as an adult conference. No moderator in SIGnet shall allow illegal messages in their conference as outlined in section 8.10. 8.11 Legal Action Due to Conferences Any conference which may be cause for legal action against SIGnet, any host passing the conference, or any system in SIGnet carrying the conference shall be deemed to be in contradiction of the policy, attitude and general concept of SIGnet. The conference in question will be indefinitely suspended from SIGnet circulation until it can be determined whether there is violation of civil or corporate law. This action should not be viewed as censorship. It is not the personal opinion of any sysop, host, or system in the network which causes this action but the governing laws and legislation of the geographic area involved. 8.12 Personal Opinions and Beliefs No host in SIGnet shall let his or her personal opinions or beliefs prevent them from allowing access to echomail of any type to any system. It is not the purpose of a host to judge or predetermine what is right or what is wrong. In the event that a host is unable or unwilling to carry a public conference in SIGnet due to personal beliefs or reasons, that host should either provide immediate alternative sources to his or her downlinks or resign the position. 8.13 Origin Line Address All echomail entered into SIGnet must contain only SIGnet addresses in the origin line. Repeated failure to comply with this regulation will result in the loss of echomail privileges. 8.14 Echomail Conference Tag Structure All echomail conferences tags distributed in SIGnet are to conform to a certain technical specification. This specification may found in section 10. 8.15 Mandatory Conferences All systems in SIGnet shall be required to carry the following conferences: (i) sig.sys.admin a general policy and admin discussion echo; (ii) sig.sys.backbone a general echomail policy and distribution discussion echo; (iii) SIGNET TICK distribution echo for nodelists, echolists, and newsletters; (iv) *C's and *EC's may require other echos mandatory for the administration of their area. Nodes in these areas are required to carry no more than one single area for each *C or *EC in their location. For example, a node would have no more than five mandatory echos at most. 8.16 Echomail Backbone An international backbone shall be established for the smooth transmission of echomail conferences between zones. (i) no gated echos shall be available on the backbone unless unanimously agreed upon by the ZECs. (ii) all ZECs must make all backbone echos available to all regions in their zone. 8.16.1 Backbone Coordinator A backbone coordinator shall be appointed by the IC. (i) the backbone coordinator shall provide and maintain an up-to-date list of echos, their moderators and echo descriptions. Section 9 - Gateways 9.1 Gateway Definition (i) A gateway is a system which permits netmail to be automatically passed through between SIGnet and other networks. These gateways are listed in the Zone 24 segment of the SIGnet nodelist. (ii) The other type of gateway is an echogate. Echogates are permitted in SIGnet only with the approval of the ZEC and only in conformation of this policy (section 8.2.x). Echogates need not be listed in the nodelist unless they perform netmail functions (see 9.1 i). 9.2 Netmail Gateways Any system performing netmail gating functions on an official basis shall be listed as such in the Zone 24 segment of the SIGnet nodelist. Application for this is simple - a netmail request to 24:24/0 stating the territory in which you are willing to gate mail. 9.2.1 Netmail Gating Automation Special software for gating netmail is not needed at this time, although difficulties may arise out of the inability for a node to be unable to respond to mail from another network. It is best if software which appends a 'via' address line at the bottom of the message to be used so that a node can find somewhere in which to respond. It is, however, required that a message be able to automatically pass through the gateway without any manual intervention. It is fully the intention of SIGnet to develop and implement software which is able to fully function as a netmail gateway. Section 10 - Technical Specifications 10.1 Technical Specifications 10.2 Technical Proposals Proposals may be made to the technical specifications section of this document by forwarding a text file with the amendment to 24:24/0 for inclusion into the written policy. The policy amendments will be hatched into the SIGNET tick conference for distribution. The entire policy document may, from time to time, be rehatched after several changes have been made. All proposals must be voted and agreed upon before inclusion into the written policy. (it is SIGnet's intention to continually keep technical updates in the policy document so that one single document may be available without having to try to find several documents to understand SIGnet's total operation) 10.2.1 Local Policy Documents A ZC may approve and institute policy pertinent only to their zone so long as the policy has been voted upon in the process outlined in this document, and the policy document is submitted to the IC. The ICs reason is not so that any ruling may be made but more so that suggestions may be made and so that similiar resolutions being made in other zones can be shown and compared to a previously instituted document. 10.3 Echomail Conference Tags All echomail conferences being distributed in SIGnet must follow a standard naming convention as outlined in this section. orgnet.distlvl.echotag orgnet - for gated mail, this will designate the origin network (ie fidonet) - for domestic mail, this will be SIG distlvl sys = for general SYSOP distribution pub = for general PUBLIC distribution adlt = for general ADULT distribution prv = private distribution nXXX = for net SYSOP distribution rXXX = for region SYSOP distribution zXXX = for zone SYSOP distribution zadm = for ZHs and ZEHs radm = for Zhs, ZEHs, Rhs, and REHs nadm = for *Hs and *EHs nXXXadmn = for net ADMIN distribution rXXXadmn = for region ADMIN distribution zXXXadmn = for zone ADMIN distribution echotag - for gated echos, this will show the original tag before gating. - for non-gated echos, this will be a unique name. 10.3.1 Conference Tag Examples (i) sig.sys.test this echo would originate in SIGnet, for general sysop distribution, with the unique tag of TEST. (ii) fido.pub.cooking this echo is the Fidonet COOKING echo which is gated for public distribution. (iii) sig.z25.chatter this echo would be a SIGnet echo for distribution within Zone 25 with a unique tag of CHATTER. 10.3.2 Tag Exceptions Beta echos being distributed within SIGnet are exempt from the above tag regulations. Authors may decide whether or not to use the above tag style or not. As well, some authors may request that support echo tags not be changed. This exception may only be made if the author is the moderator of the conference. 10.4 Echo Useage (i) test messages may not be entered into international echos for any reason except by the moderator. It is up to the NEC and NC to establish some sort of method of testing a link with a node; (ii) echomail feeds are a priviledge and ZECs and the IC retain the right to request a link be limited access to local echos only if they are unable to control their users or themselves from abusing echos; (iii) similiar to ii, the ZECs and the IC retain the right to request a link be terminated in the event that a sysop becomes abusive in netmail or echomail with regards to violation of policy or misuse of echomail; (iv) commercial messages in echomail are allowed only in conferences to which it is pertinent. Also, a commercial message (meaning one that advertises or reviews any product or service for distribution - whether free or not) may not be cross-posted all over the backbone. The ZEC has the right to request a link be terminated should a user or sysop repeat this offence. Section 11 - Cost Sharing 11.1 Zone Level Cost sharing at the Zone level depends in some measure on the methods adopted at the Regional levels. However, in order for it to be implemented, it must be accepted by a majority vote of all the sysops in the Zone according to policy. In general terms, Regions which have implemented Regional cost sharing plans should forward a part of the contributions they receive to the ZEC. 11.2 Regional Level If a SIGnet Region wishes to implement cost sharing, it may do so, as long as the following conditions are met: (i) Regional cost sharing plans will be evaluated on a "per request" basis; a request must be made by the REC to the ZC, stating that he/she wishes to implement a cost sharing scheme, and outlining the methods. (ii) The cost sharing plan must be approved by a majority vote from the sysops of the affected Region (one vote per Sysop, not per node). Voting will be conducted as outlined in this document. If the majority vote goes against the cost sharing plan, the REC may NOT implement it. (iii) If the cost sharing plan is accepted, any sysops who still do not wish to participate may NOT be expelled from SIGnet; they may choose to link to another system outside the Region, as long as the REC of both Regions allow this, and the ZC is informed. The sysop is however entitled to receive the mandatory SIGnet echos from the NEC or REC, as well as having net mail put on hold for him/her. 11.3 Net Level Nets may not impose policies or cost sharing schemes which conflict with the policies which govern the Region of which they are a part. If an NEC feels that he/she cannot bear the cost of polling the uplink for echo mail, there are two possible courses of action: - The position may be relinquished to someone who is able to satisfy the requirements; - If for any reason the previous solution cannot be adopted, the NEC may retain a portion of the funds donated by the nodes in the net to help defray the costs. This portion may not be greater than 25%. In no case should the sum donated by each node be greater than that required by the Regional cost sharing plan. Should this second course of action be implemented, permission must first be given by the REC for that Region affected. Section 12 - Policy Changes 12.1 Initiating Amendents Policy may be added to or changed by means of a special resolution to the IC or your ZC. Discussion and formulation of policy changes will be made by a Policy Council consisting of the IC and ZCs. Once formulated, the policy shall be put forth to the SIGnet membership at large for ratification. A simple netmail message or echomail message in SIG.SYSOP.ADMIN to the IC and your ZC will initiate policy discussion. (i) should the Policy Council decide that it is in the best interest of the membership to institute the policy prior to ratification, they may do so with the unanimous agreement of the IC and ZCs. (ii) the IC or any ZC may veto any policy change from going to ratification until further discussion takes place within the Policy Council. 12.2 Local Policy Only at the zone level, policy may be instituted by means of a public vote. This policy may not be initiated if the following conditions are not met: (i) greater than 50% of the sysops in the zone must be in agreement (all sysops must vote as per section 2.8); (ii) the policy does not affect, in any way, the operation of another zone in SIGnet; (iii) the policy does not contradict any portion of this policy document; (iv) the policy document is submitted to the IC as per section 10.2.3. Section 13 - Copyright and Ownership of SIGnet 13.1 Copyright Notice SIGnet, SIGnews, SIGdiff, SIGnodes and the SIGnet Policy Document are all trademarks and are Copyright (C) 1991 by Jamie Penner. All rights are reserved worldwide and no use of the copywritten trademarks may be used with the prior written consent of the owner. This copyright in no way controls the contents of the nodelist but only the names SIGnodes and SIGdiff.